In old versions of Min, userscripts worked by saving a file named ".js": https://github.com/minbrowser/min/wiki/userscripts/_compare/6fd447be081f8f9911ed8100d99b6361c7d8fb6a

When we switched to the new format, we kept support for the old format so that existing userscripts would keep working, which is why the code allows that, even though it's not mentioned in the current docs.

We could remove that support, but I don't see much reason to either; do you think it should be removed?

Regarding the actual change, I think it would be good if (as the issue author suggests) the folders are mapped to submenus of the userscripts context menu, for scripts with the context-menu type. Is that something you'd be willing to add in this PR?

Thanks for your reply !

Interesting, my question was mainly raised by this bit of code where every script needs to be in the format seems to necessarily be www.website.js.
Regarding what you sent me, there's maybe a bit of confusion about documentation 😄

My main concern about removing it was introducing a breaking change.
But, considering a breaking change isn't something bad if well documented, I think we should introduce something like tampermonkey with a unique (well documented haha) format for script metadata.
To put a clear perspective of what I think, let's say the every script's header should be :

/*
target: *.github.com | * | main.github.com/page/12234 
name: Script 
author: entropie-33
github: https://github.com/entropie-33/...
*/

For the issue itself, since the need wasn't clearly expressed for the UI part of having scripts/subfolders mapping I figure out it was not necessary since to have a look at the organization of your scripts you cloud simply click the button "see folder".
However I see more value to have a metadata visualization where you could easily see which scripts applied to what kind of URL and being able to activate certain scripts only via a checkbox.

Btw what would be the value to implement tampermonkey to benefit from their tool on this ?

Also, I take the shot to ask you whenever you have considered adding tests and if there's a methodology for it ?
If not I'd be glad to help on this.

I kinda like the projet and love the idea that I'm helping improving my browser which was the last not privacy oriented software in my stack.

Nonetheless I'll open a new PR for script visualization since, in my opinion this one includes enough modification; from subfolder loading to refactor, I wouldn't have too much modification on this PR because the full functionality will require a lot more modifications than the ones here.

Oh I think the confusion is maybe this part: https://github.com/minbrowser/min/blob/master/js/userscripts.js#L106 - "domain" isn't named very well, since it's actually just the file name.

We first check for a header, which is similar to what you're suggesting (and what the current documentation describes): https://github.com/minbrowser/min/blob/master/js/userscripts.js#L115

Only if there is no header do we assume the filename is a domain: https://github.com/minbrowser/min/blob/master/js/userscripts.js#L124

You can try this out - if you write a script with any file name and a header matching what the current documentation shows, it should already work.

Supporting Tampermonkey directly would be nice, but implementing Chrome extension support would require a lot more work.

There are no automated tests currently, but you're welcome to add some if you'd like.

Okidoki makes a lot more sense for the naming haha !

Then there's 3 cases :

1. headers present and we parse them
2. No header and might be legacy (global)
3. No header and just a script

Absolutely no problem with tests I wasn't trying to brag nor be condescendant, hope you didn't take it as criticism.
I'll look into adding tests at least to userscripts.

Would it be that bad if we break legacy ?

Anyway thanks for your reactivity !

Currently, it's:

1. If there's a header, we use the header.
2. If there's no header, we assume the file name is a domain name, and apply the script to any page whose domain matches.
3. If the script has no header and the filename isn't a domain, it won't work.

I'd be OK with removing the legacy support if you think there's a reason to, but it also seems like it'd be fairly easy to keep the legacy support around. As long as that's the case I'm inclined to keep it.

Absolutely no problem with tests I wasn't trying to brag nor be condescendant, hope you didn't take it as criticism.

It's fine, I know tests would be valuable; I've just never had the motivation to write them.

I'd be OK with removing the legacy support if you think there's a reason to, but it also seems like it'd be fairly easy to keep the legacy support around. As long as that's the case I'm inclined to keep it.

No problemo ! I think the userscript base is good but needs a bit of refactoring in order to reflect clearly what it does. I'll work on this.

It's fine, I know tests would be valuable; I've just never had the motivation to write them.

Sure, I'm not that comfy with Electron tho but would be a nice try.